Today, many enterprise server applications and products process thousands of client requests each day. These server applications are typically deployed in a load balanced environment to allow requests (also referred to herein as “messages”) coming from different clients to be served by different servers from a cluster (also referred to herein as a “pool”) of servers. If a request received at a server is meant to be routed to a destination client, the request may flow through other servers in the same pool, or servers in a different pool en route to the destination client. These server applications are commonly based on the client-server paradigm, where the application or system is split between the server (e.g., server tasks) and the client (e.g., client tasks). In client-server terminology, a client sends a request to a server, according to some protocol, typically asking the server to perform an action and the server responds to the client's request.
For example, enterprise server applications, such as MICROSOFT Live Communications Server 2005 (LCS), are deployed as a pool of stateless servers, and messages flow between the clients utilizing the application by traversing multiple servers in one or more pools. In addition to, or as part of the server application, the individual servers may host custom applications, such as applications that perform authentication services, applications that perform logging services, applications that perform archiving services, applications that perform statistical data collection, etc. These applications accordingly process the messages that flow through the server—e.g., to perform some custom processing—before the messages are forwarded to the next server in the route to their destination.
Often times, an instance of an application that is running on one server needs to know whether a message flowing through the servers has already been processed by another instance of the application running on another server. For example, an archiving application may be running on each of the enterprise server application servers to log messages to a database. When a message arrives at the first enterprise server application server, the instance of the archiving application running on that server logs the message. The message then travels to a subsequent enterprise server application server, and the message is processed by another instance of the archiving application. In order to avoid re-logging of the same message, the archiving application needs to know whether the message was previously logged—i.e., processed—by another instance of the archiving application.
It would be desirable to have a technique for propagating information regarding the state of a message between instances of an application running in a distributed environment.